Being able to debug your electron application is critical for building reliable apps and having covered
the initial application structure, you've probably already figured out how the renderer process will
be debugged and inspected.
This line here, main window being that main application window, we are creating Web content, open
dev tools.
This method basically opens the chrome dev tools for the window.
It's called on as soon as it's created, resulting in this window here, a completely standard version
of the chromium dev tools, exactly the same as you're familiar with in your desktop browser, allowing
us to debug any code run inside of the Web contents of this window.
So the loaded HTML JavaScript access, that's pretty straightforward then.
But let's now see how we can debug the main process instead.
Everything here in this main script and its dependencies, or in other words, the notice process.
Now there's a number of ways to inspect this process, including using visual studio code or a similar
IDY and a link to the relevant documentation explaining that in the lesson resources for our purposes.
However, I'll once again use chrome chrome dev tools, provide excellent JavaScript debugging, so
it's a perfect fit for this.
Step one is configuring Chrome to listen on the port will be debugging.
The app node essentially creates a websocket connection on a local HTTP port for debugging.
So to start the app with debugging enabled, we can run electron with an inspect flag equal to the port.
We want to use anything above Port 1023 should do.
I'll make this Port five eight five eight running in the current directory, same as our NPM Start command
center and the app launches as normal.
But in the background we now have the node debugger.
Listening on Port five eight five eight, as mentioned, will be using the chrome inspector.
So in a new chrome window, navigate to chrome colon slash, slash, inspect.
Which brings us to this dev tools devices menu.
Keep in mind that this page might look different on newer versions of Chrome.
Click on Configure and add that new debugging session as a target localhost five eight five eight.
Done and immediately our electoral map shows up under devices where we can now inspect the main process
for this target by clicking this inspect link, launching a new death toll window for our assessment
process, click into the sources tab, their main dossiers being listed as a resource.
OK, so with the Chrom inspector configured, let's see how to trigger breakpoints and debug our code.
Close this back to MINDGAMES and to demonstrate, I'll add a simple breakpoint in this main Windows
closed event, meaning the callback that runs when we close our one and only up window debugger being
the standard breakpoint trigger save.
Restart the app with the inspector now back in the chrome window, we have to relaunch the inspector
for this target.
There we see the debuggers statement.
So go ahead and close this window.
And the breakpoint is triggered, stopping the window from being closed and jumping a straight into
this point in the code resume code execution year and the window continues to close.
So this is about as simple as it gets for triggering breakpoints in the main process.
But as we have to relaunch this inspector window for each new section of the app, we might sometimes
need to execute an immediate breakpoint.
As soon as the app is started, allowing us to step through each part of the app, start up or remove
this break point back to the terminal.
And now to break on launch, we can run instead of just an inspect flag, inspect Beeac or break same
port enter.
This time nothing happens as the main process get halted before it can create my new window, switch
over to Chrome and relaunch the inspector.
We see the app being halted on the very first line of the script, electronic users to start the main
process where we can now step over into and out of code right from the start.
Very useful, especially for debugging functions in the main process that happen on launch.
For example, this be creped hash that gets logged out.
If we don't break prior to this running, we'll never get to open an inspector window fast enough to
see it.
So instead add the desired break point right before this log message break on start as before we get
no window, of course, as it's all halted, relaunch the inspector, but this time with the inspector
ready and the breakpoint said simply allow the app to continue execution and the app breaks where we
specified in that decrypt callback where we can inspect the value of this hash in real time.
So as you can see, once configured debugging, the main process is pretty simple.
If you would like to learn more about debugging with chrome dev tools, I've linked to some resources.
In the next lesson, we'll see how to reset our project before getting started with the electron API.